在前半段的系列文章，我們把視野縮的很小，一篇一篇著重在每日趕進度的技術細節，看看怎麼使用Python來實作出規格書中的每一個功能，驗證每一個步驟的正確性。

現在有機會重新用較寬廣的視角來重新審視這些實作過程的技術環節，可以怎麼思考與運用。

前一篇我們分析了使用者情境，以及豐收款的服務範圍，技術與環境的選用。在確保了讀文章的你，有幾個符合條件的可能性，不會浪費時間：

1. 你本身具備開發能力，或者可以聽懂開發技術 (例如你可以找外包來寫)
2. 需要永豐API的線上收付款服務
3. 或者即使你不直接使用永豐API，但單純想了解線上金流的概念或技術實作
4. 即使換成了其他語言或框架你也可以駕馭

以上第三點我覺得其實蠻重要的，因為其實在沒有接觸過「線上金流技術」這一塊(我指的僅是「使用服務」，不是當無類似永豐API端的角色)，先不管到底用的是不是永豐金的服務，很少人有把握知道自己的網站若缺少了金流服務，到底可以怎麼做，串不串的地來，心中自然都會感覺到金流的處理很困難，只覺得那是一片黑盒子，往往想了解但不得其門而入。

就算有機會和提供金流服務的公司取得資料，也只有很生硬的規格書供閱讀，而沒有比較具有教學性質或者分享性質具「人味兒」的文章讓自己參考。這是iThome鐵人賽這次主題我認為相當有意義，至少有機會藉由這個活動產出了不少的文章，提供未來想了解的讀者有完整系列文可參考。

重新盤點技術關鍵點

在寫完了一系列的文章，其實每天寫有關永豐金API文章的過程，有絕大半的時間都是花在反覆實作與發現問題解決問題，我個人的理念是希望每一篇寫作幾乎都是希望在當天發表的文章就是「正確實作後的內容分享」，盡可能不要以邊卡住邊撰寫的方式提供可能誤導的訊息給讀者。所以真正花時間的不在撰文本身而已，而是要花相當多時間試誤與解決問題。

這邊就把過去這些日子對於永豐API實作技術面的關鍵點整理一下，而且這個部份必須是全部走完實作後，再來寫才可看的到全貌之處。

整理一下單向發送API到永豐接收的流程全貌

API訊息服務

在上圖中我們可以看到幾個我們實作的關鍵點，由於最左側的原始明文的產生，是和不同的訊息內容有關。再複習一下，這裡的訊息內容，簡單一點來說，就是依不同的功能所需要和永豐API提出的功能服務，而因為永豐API把這樣的功能稱之前「訊息」，因此無論是要「建立一篇訂單 (但內含了需要不同的付款方式)」或是「查詢某個付款狀態」，對API叫用而言都是一則「訊息」。

所以有關服務訊息的部份，在你的商業邏輯是要和中間的資安處理流程拆開來。

簡單說，你會需要依服務功能拆成：

1. 建立訂單，但需使用ATM付款
2. 建立訂單，但需使用信用卡付款
3. 取得PayToken
4. 拿PayToken去問回付款結果
5. 以訂單條件詢問付款結果

而上面這邊的服務，因為有絕大部份會使用相同的「訊息內容」JSON格式，所以可再進行共同部份的重構拆解。

有關資安處理流程

把上面這邊先準備好後，接著就是「無論哪一種訊息服務都需要的資安處理流程」，設計要點，請務必從左側的服務商業邏輯中獨立出來！

如同我先前說的，雖然規格書是先講Sign安全簽章，再講AES Message加密，但我始終不認為是這個順序。我覺得以資安的意義來說，你要先知道怎麼把你手上的明文加密成密文，接下來才談收到密文的人，除了把密文解開後，再來談「怎麼確保這是加密者的原始未遭篡改不可否認的內容」。當然兩者就「技術面」而言，是平行不分順序的，但我認為「意義上」是有順序的。

如果你只看到「傳送端」這一塊，自然覺得先加密Message再算Sign還是相反過來，好像都一樣，但如果我們把右邊「永豐API接收訊息」也考慮進去，就會知道「必須要先解密」，拿的到明文，才能進行「Sign的重新運算與產生」，然後拿運算結果去比對收到的Sign是否一樣。

因此，我們先看API傳送端的邏輯，上面的圖只看到我們需要處理「AES加密」和「產生安全簽章」的處理流程，但如果看完右側永豐收到我們的加密訊息後要多做「AES解密」以及「比對簽章」。因此這部份我們也需要一併加在我們的流程裡面，原因是訊息是一去一回的，所以我們建立訂單後，永豐API需要回覆我們ATM虛擬帳戶或者信用卡刷卡網址，永豐回傳給我們的內容，也會比照我們傳出的方式進行加密與附上安全簽章。我們的角色就會反轉過來，如同右上角的圖一樣，需要進行一連串的安全處理流程，

所以這邊再加上「AES解密」以及「比對簽章」，如圖用紅框所示。

資安防護的關鍵點

那接著我想談一下在這過程中，哪些點是為提升資安而加強防護的部份。

盤點有關資安相關的重要因子，整個高度資安防護是由以下綜合建構而來

1. HashID：由4組Hash代碼產生得固定值，作為AES Key加密對稱金鑰用途。(需注意人為保密)
2. Nonce值：每次詢問，用完即丟，1分鐘時效。 (高動態具時效性)
3. IV值：加解密固定的對稱金鑰時會搭配使用才能正確加解密，基礎是由每次變動的Nonce而來 (高動態具時效性)
   前三項主要使用AES-CBC作加密產生密文
4. Sign的產生：
   • 以「永豐自定的取捨規則」產生內文雜湊 (取得規格書者就知道，有一點半公開的密秘)
   • 加上HashID (固定值，需作到人為保護)
   • 加上Nonce值 (高動態具時效性) --> 這是我認為相當重要的關鍵，因為其他點都是固定不變的或自訂規則。
   • 整個再做SHA256 (產生數位簽章，看起來是無法閱讀的代碼，但他是可逆的，不是加密法！)
5. 整個傳輸過程需符合HTTPS TLS 1.2
6. Nonce的取得來源的IP需要相同 (永豐API端會紀錄)

安全保護力解析

因此在雙方API交換資料的過程中，基本上符合以下資訊流程：

1. 傳屬通道本身已加密(TLS 1.2)
2. 若不慎被有心人事截取封包，且被解開了 → 訊息本身是以AES加密的
3. 若固定的AES Key (HashId)在人為保護疏失下已被有心人士取得，那麼要解開AES就有非技術性的風險存在
4. 但是要解密AES過程，是需要輸入初始向量IV值 (由Nonce而來)，已大大提高被破解風險
5. 若是能在一分鐘之內破解 (現在的風險為內容遭不合法方式檢視)，但至少要防止被資料篡改，因此這個一分鐘就失效且一次性的Nonce就發揮了高度的作用。
6. 如果真的被破解，而且也被嘗試的要進行資料修改再送出，但還有一個重要的安全簽章Sign作比對
7. 安全簽章裡面有一些規則是永豐自己定義的，要取得規格書的人至少才知道不是只是拿原訊息內文JSON直接作SHA256雜湊這麼簡單，還包含了屬性排序、某些多值欄位不放入、將JSON格式轉為類似URL Parameters的Key-Value串接。不過，以自訂義雙方內部規則作為安全防護，個人覺得是很有限度的防護方式。基本上就是只要規則被知道就無防護力了。
8. Nonce的IP的要求來源是會在永豐端記錄，這個機制的防護規則是能防外賊但防不了內鬼。

由上面這一些分析，可以了解同樣是API的呼叫，若對於資安要求沒那麼高的服務，基本上不會使用這麼全面的規則與流程，但也由於我們公開透明的研究完這些實作細節，可以了解到要和永豐作一次API處理，是相當高度安全的，也由此來讓系統對接用戶，以及終端使用用戶(如果他們真的有機會了解到的話)都可以放心的作資料交換。